下面會講到很多安全相關需求 (Requirements)，記下來的目的是提醒自己應用到系統中。關於流程圖，安總我比較喜歡瀑布式的流程，也就是第一步、第二步、第三步、...，一步一步要做什麼，原因是，人的頭腦是單線式執行的動物；再來就是一步一步比較好執行，這是心理層面。所以底下的流程圖，雖然有「循環 (Cycle)」的性質，但我一律畫成線型方便執行。

安全性需求 (Security Requirements)

通常我們在軟體需求規格中，會加入一個 Security Requirements 的區塊，藉此在設計階段，就將安全性的需求給考慮進來。我想 CIA 三人幫是很基本的元素，分別是：機密性 (Confidentiality)、整全性 (Integrity)、可用性 (Availability)。(後面文章再詳談)

另外一個安全性需求叫作可認證需求 (Accountability Requirements)，我畫了一個流程圖如下：

1. 識別 (Identification)：
   使用者告訴系統他是誰，例如：輸入 ID。ID 必須是獨一無二的，才能正確地分辨出每個人。
2. 鑒別 (Authentication)：
   系統判斷使用者是否真的是他宣稱的那個人，例如：輸入 Password。這是基於帳號密碼為只有本人跟系統本身才知道的共享秘密 (Shared Secret)，所以只要可以正確輸入密碼，系統就可判斷使用者為這個帳號所代表的人物。
3. 授權 (Authorization)：
   系統根據該帳號被定義之角色 (Role)，授與該使用者特定權限，標準的論述如下，"Is user X authorized to perform operation P on resource R?"
4. 稽核 (Auditing)：
   這個在 V Model 之驗證流程 (Verification Process)(產品轉階段)，和 CMMI 的過程與產品品質保證 (PPQA)(定期) 的時候就會做了，放心。但我們要產出一個報表來呈現，方便稽核。

看到上面那個流程圖，是不是讓您想到了「組態管理 (Configuration Management)」？接下來我們就要講解變更管理 (Change Control Management) 的應用性好處。

組態管理之安全性應用 (Configuration Management)

值得注意的是，組態管理的範圍不只有 Prodcut 本身，還包括專案過程中所有的 Work Products，如此才能帶出完整的安全性好處喔：

1. 避免安全性下降 (Security Reduction)：避免因為沒有被控制之變化，造成系統的安全性下降。
2. 可追溯性 (Traceability)：可追蹤所有過程中的修改，是否都符合安全標準。
3. 可回復性 (Ability to Roll Back)：在意外事件發生後，可以立即回復到發生前的狀態。

資料分類保護機制 (Data Classification)

其實我覺得一般企業的資料落失保護 (Data Loss Protection) 機制做得還不錯，所以這部分我就快速帶過：

1. 貴重資產照護人 (Custodians)：
   規格就找規格組長，軟體就找軟體組長，程序就找程序組長。
2. 資產分類 (Classifiction)：
   每份資產一定只有一個 Owner，問那個 Owner 這份資產之機密程度與分類原則，安全組 (Security Staff) 接著複審這份清單結果。
3. 例外整合 (Exception Integration)：
   複審時就會發現，大家觀念不一致，這時候把差異圈出來，坐下來談好一個版本，看看大家以後要怎麼幹，並修正到我們的分類原則中。
4. 建置系統控制 (Security Control System)：
   強勢要求每一位資產放到合法的儲存區域，限期改善並搬遷所有不合法區域儲存的資產，時間一到就動用 IT 的力量中斷服務；強勢推行「資料不落地」政策，徹底禁用 USB；於每一台公司電腦安裝資料保護守門員，立即阻斷所有不合法的資料傳輸及讀寫活動。
5. 發布周知 (Enterprise-wide Awareness)：
   於中央成立一個安全功能組 (Security Roles)，主要成員包括資深管理階層 (樹立由上到下決心執行之威信形象)、Owner (每份資產之負責擔當)、貴重資產照護人 (負責每月發信給總經理，有誰、有什麼事件違規了)、User (負責遵守規則)、稽查員 (負責定期稽查)。

集團在 2015 年給所有高階經理人閱讀過的一本書

《未來的犯罪 Future Crimes》